OTN (Optical Transport Network) is a standard which defines an encapsulation protocol permitting the optical transmission of a wide variety of different signals over a common optical medium. OTN provides the flexibility for transparently multiplexing and mapping synchronous and/or asynchronous client signals (each of which may be represented in their own standard protocols) over fiber-optic networks, including optical networks employing Wavelength Division Multiplexing (WDM). The OTN standard was developed by the ITU-T, which defines OTN as a set of Optical Network Elements (hereinafter referred to as “nodes”) connected by optical fiber links, able to provide the functionality of transport, multiplexing, switching, management, supervision, and survivability of optical channels carrying client signals. ITU-T Recommendation G.709, entitled “Interfaces for the Optical Transport Network,” defines various aspects of OTN, which may be referred to as a “digital wrapper” technology that defines a layer hierarchy for payload encapsulation, Operations, Administration, and Maintenance (OAM) overhead, forward error correction (FEC), and multiplexing. The result is a transport standard that includes the benefits of Synchronous Optical Networking (SONET) and Synchronous Digital Hierarchy (SDH) protocols (e.g., resiliency and manageability) but with improvements for transporting asynchronous data payloads such as Ethernet. Accordingly, OTN was specifically designed to be a multiservice transport container for essentially any type of data service, from TDM to packet, and this flexibility is one of OTN's advantages. OTN has been widely deployed for transport within long-haul networks (referred to herein as “transport networks”), particularly because OTN's inherent FEC features enable reliable optical transmission over longer distances.
FIG. 1 shows a simplified diagram of an exemplary OTN layer hierarchy 100 and its associated frame structures 150 defined in ITU-T Recommendation G.709. The OTN layer hierarchy 100 may be broadly divided into four layers: classified as Layer 3 (L3), Layer 2 (L2), Layer 1 (L1), and Layer 0 (L0). Layer 3 may include various packet-based protocols such as Transmission Control Protocol/Internet Protocol (TCP/IP) and Multiprotocol Label Switching (MPLS). Layer 2 may include Ethernet, ATM, and Fibre Channel. Layer 1 can include SONET/SDH, and OTN sub-layers Optical Payload Unit (OPUk) 104, Optical Data Unit (ODUk) 106, and Optical Transport Unit (OTUk) 108. Layer 0 may include OTN sub-layer Optical Channel (OCh) 109. Because various OTN sub-layers may exchange data using a variety of different rates (e.g., OTU1, OTU2, OTU3, and ODU0), these rates may be collectively referred to as having a “k” appended to the appropriate frame's acronym, such as “ODUk” and “OTUk.”
Further referring to the OTN Layer Hierarchy 100, Layer 3, Layer 2, and Layer 1 may operate on their respective data units in the electrical domain, while Layer 0 may operate in the optical domain. End user services, which are referred to herein as “Clients” 102, may include IP, MPLS, Ethernet, ATM, FC, SONET/SDH, etc., and thus the Clients 102 may span multiple layers (e.g., L0 through L3).
Typically, Layer 3 and Layer 2 may be associated with packet switching networks, which are also known as connectionless networks. In a connectionless network, traffic flow may traverse one or more network paths between predefined endpoints, where the paths traversed by the traffic flows between the predefined endpoints are not pre-specified. Layer 1 and Layer 0 can be associated with connection-oriented networks, such as circuit switched and/or virtual circuit switched networks having a predefined traffic path, which may utilize Time Division Multiplexing (TDM) over both electrical (L1) and optical (L0) physical channels.
Further referring to FIG. 1, the OTN layer hierarchy 100 can be associated with the OTN Frame Structures 150. The end user services may provide a Client signal frame 152 in a variety of different protocols to the OPUk sub-layer 104. The Client signal frame 152 may include signals using synchronous networking protocols, such as SONET and SDH, and/or asynchronous protocols, such as ATM, Ethernet, and/or Fibre Channel. The OPUk sub-layer 104, which contains all the timeslots in the OTN frame, may encapsulate the Client signal frame 152, and add OPUk overhead, to produce an OPUk frame 154. The Client signal frame 152 is essentially unmodified by the network, aside from being mapped at the source node and demapped at the sink node. The ODUk sub-layer 106, which provides path level transport functions, receives the OPUk frame 154, appends its own ODUk overhead, and encapsulates the OPUk frame 154 to produce an ODUk frame 156. The OTUk sub-layer 108, which provides section-level overhead, receives the ODUk frame 156, appends its own OTUk overhead and Forward Error Correction (FEC) information, and encapsulates the ODUk frame 156 to produce an OTUk frame 158. The OCh layer 109 serializes a plurality of OTUk frames 158, and appends its own overhead to produce the OCh frame 159.
FIG. 2 shows a top level block diagram of a node 200 which may perform networking functions at different layers. The node 200, for example, may function as a dual purpose switch (such as, for example, a carrier class Ciena 5400 series switch), that can simultaneously perform switching on both Layer 1 traffic paths and Layer 2 traffic flows. Such nodes 200 may be referred to herein as a hybrid switch. Node 200 can provide switching functionality to interface client services with transport networks, which are typically Wide Area Networks (WANs). For example, one application could be to provide connectivity between a backhaul network and one or more cell towers, and thus provide Ethernet services from cell towers through the transport network (e.g., an OTN/SONET/SDH optical network).
The node 200 may include a plurality of line modules 205, 210, and 230 having client-side ports (206, 211, 231) for transferring data with a variety of different client services over fiber and/or wire connections (as indicated by solid double-arrow lines in FIG. 2). The line modules 205, 210, and 230 may communicate to at least one hybrid switching module 220 over a backplane connection (also referred to herein as “backplane”) represented by the thin dotted lines shown in FIG. 2. The node 200 may further include at least one line module 240 having transport-side ports 241 for communicating over the transport network. Data may be transferred between the hybrid switching module 220 and the line module 240 over the backplane connection. As described in more detail below, node 200 may process both L1 traffic paths, such as OTN Subnetwork Connections (SNCs), and L2 traffic flows, such as Ethernet transfers, in a parallel manner. In FIG. 2, the L1 traffic paths are illustrated in heavy gray dotted lines, and the L2 traffic flows are illustrated in heavy gray solid lines.
The hybrid switching module 220 that may utilize a plurality of switch fabrics which can simultaneously perform switching at different layers. For example, the hybrid switching module 220 may utilize a converged L1/L2 switch fabric. The converged L1/L2 switch fabric can operate using parallel L1/L2 fabrics having a plurality of ASICs, and/or a single fabric ASICs with multiple fabric capability. FIG. 2 illustrates the hybrid switching module 220 operating using two parallel fabrics, where the L1 switch fabric 222 operates on the L1 traffic paths, and the L2 switch fabric 226 operates on the L2 traffic flows. Regardless of the ASIC implementation, the hybrid switching module 220 may supports backplane interfaces both separate L1 and L2 connections, and hybrid cards having dual L1/L2 fabric interfaces.
Line module 240 may be referred to as a transport-side line module and can include one or more optical services line modules and/or Dense Wavelength Division Multiplexing (DWDM) modules. The transport-side line module 240 may transfer data over L1 traffic paths between the hybrid switching module 220 and the transport network. The L1 traffic paths may be provided over the backplane connection. In one aspect, the transport-side line module 240 may receive ODUk frames from the hybrid switching module 220, and transform the ODUk frames into OTUk frames for transmission over a transport-side port 241, and subsequent transmission over the transport network. In the reverse direction, the transport-side line module 240 may receive OTUk frames from the transport network over the transport-side port 241, convert the OTUk frames to ODUk frames, and send the ODUk frames over the backplane connection to the hybrid switching module 220 through the L1 switch fabric.
Further referring to FIG. 2, the node 200 may include a plurality of client-side modules 205, 210, and 230 for transferring various signals between the hybrid switching module 220 and various client services. For example, node 200 may include one or more client-side optical services line modules 205, having client-side (also referred to herein as “front-side”) L1 ports 206 supporting L1 traffic paths, which can include support for various SONET, SDM and OTN optical data frames, and can include ports for client services such as OC192, OTU2, OTU3, OC768, etc. The optical services line module 205 may transfer L1 traffic with the hybrid switching module 220 over a backplane connection using the L1 switch fabric 222. The L1 switch fabric 222 may provide L1 traffic from the optical services line module 205 to the transport-side optical services line module 240 for subsequent transmission over the transport network. In the reverse direction, L1 traffic may be received by the transport-side optical services line module 240 from the transport network, and switched to the client-side optical services line module 205 through the L1 switch fabric 222. Alternatively, as will be explained in more detail below, L1 traffic may be exchanged between the client-side optical services line module 205 and a hybrid services line module 230 via the L1 switch fabric 222.
Additionally, node 200 may include one or more client-side packet services line modules 210 for supporting L2 traffic flows, which can include support for various Ethernet or other packet-based services. The packet services line module 210 may include client-side ports 211 for Ethernet client services such as 100 GbE, 10 GbE, etc. The packet services line module 210 may transfer L2 traffic between the hybrid switching module 220 over a backplane connection, where the L2 traffic may be natively switched by the L2 switch fabric 226. The L2 traffic flows may be switched to other modules supporting packet services. For example, as shown in FIG. 2, the hybrid services line module 230 may support packet services and have client-side ports 231 which support Ethernet, and thus can exchange L2 flows with the packet services line module 210. Moreover, as will be described in more detail below, L2 traffic flows from the packet services line module and may be converted to L1 traffic paths for switching on the L1 switch fabric 222.
Further referring to FIG. 2, node 200 may also include hybrid equipment such as, for example, the client-side hybrid services line module 230 which may process both L1 traffic paths and L2 traffic flows. In the embodiment shown in FIG. 2, the hybrid services line module 230 may be an Ethernet Services Line Module (ESLM) having client-side Ethernet ports 231. The client-side ports 231 may support, for example, 10 GbE, 100 GbE, and/or NxGbE client services. As shown in FIG. 2, L2 traffic flows (e.g., Ethernet packets) may be switched directly at Layer 2 between packet services line module 210 and the hybrid services line module 230. Specifically, L2 traffic flows at the hybrid services line module 230 can be transferred through an Ethernet PHY/MAC module 234, and further processed (e.g., encapsulated into L2 frames) by packet processor (PP) 236. The processed L2 traffic flow may further be exchanged over the L1/L2 fabric interface 232 and provided over the backplane connection associated with the L2 switch fabric 226 in the hybrid switching module 220. The L2 switch fabric 226 may switch the L2 traffic flow between the hybrid services line module 230 and the packet services line module 210. Alternatively, L2 traffic flows, which may be associated with either the client-side ports 231 or the L2 switch fabric 226, may be mapped by the packet processor 236 into L1 traffic paths and provided to backplane L1 termination points 238 (also referred to herein as “backplane ports”). For example, as shown in FIG. 2, by using General Framing Procedure (GFP), the L2 traffic flows (e.g., Ethernet packets) may be mapped by packet processor 236 to ODUk frames (e.g., according to a frame structure defined in ITU-T Recommendation G.709), and provided to the backplane L1 termination points 238. The L1 traffic paths may be transferred over the backplane connection associated with the L1 switch fabric 222 via L1/L2 fabric interface 232. The L1 traffic paths may be switched with client-side optical services module 205, or transport-side optical services line module 240 for subsequent transfer over the transport network. For all of the L1 traffic paths and L2 traffic flows shown in FIG. 2, the traffic may be exchanged bidirectionally. So for example, L1 traffic received over the transport network via the transport-side optical services line module 240 may be switched over the L1 switch fabric 222 to the backplane L1 termination points 238 via the L1/L2 fabric interface 232. The L1 frames may be mapped to L2 traffic flows by packet processor 236, and provided to the L2 switch fabric 226 via the L1/L2 fabric interface 232, for switching L2 traffic flows to/from the packet services line module 210.
Because of the independent backplane connections to both the L1 switch fabric 222 and the L2 switch fabric 226 provided by the hybrid services line module 230, the backplane L1 termination points 238 may be exposed as logical ports on the L2 switch fabric 226 and simultaneously serve as termination points for L1 traffic paths (e.g., Generalized Multiprotocol Label Switching (GMPLS) Label Switched Path (LSP) endpoints, or Optical Signal Routing Protocol (OSRP) Subnetwork Connection (SNC) endpoints. It is possible that the hybrid services line module 230 have a relatively large number of backplane L1 termination points. For example, the Ciena 5400 series switch can have up 80 ODU0 Connection Termination Points (CTPs) provisioned on a single card.
While the multiple layer architecture of the hybrid switching module 220 and the hybrid services line module 230 provides switching flexibility, the combination of simultaneous L1 traffic paths and L2 traffic flows can complicate protecting the hybrid services line module 230. As used herein, “protecting” networking equipment refers to configuring the equipment so that a component and/or sub-component failure does not stop or unduly restrict the flow of network traffic. Protecting network equipment typically involves configuring the equipment with some level of redundancy so that network traffic is maintained at a specified level within a specified period of time from the failure event. For example, with traditional Ethernet switches, equipment can be protected using IEEE 802.3 link aggregation groups (LAGs), which can provide protection at the port level by allocating resources among work ports (i.e., utilized for traffic flows under normal conditions) and protect ports (i.e., utilized for traffic flows when the work ports experience a failure). Another option is to configure an entire card as a dedicated hot standby, where all provisioning is duplicated on a protect card. The LAG approach may be more common since it can provide port level allocation of protection resources, thus providing greater flexibility. For example, some ports on the card may be used for unprotected services, while other services can be afforded varied levels of protection on a port-by-port basis.
In the case of the hybrid services line module 230, a one-to-one relationship between the work and protect ports may not exist, as the L2 traffic flows transferred within the hybrid services line module 230 can may be split L2 traffic flows and L1 traffic paths. Additionally, the backplane L1 termination points 238 (e.g., the backplane ODUk ports), which are exposed as logical L2 termination ports to the L2 switch fabric 226, also should be taken into consideration in any protection scheme. A conventional LAG (such as one using active redundancy (1+1) or passive redundancy (1:n)) that includes the backplane L1 termination points 238 (e.g., backplane ODUk ports) may have the disadvantage of utilizing redundant connections through the transport network (e.g., redundant OTN trunks), thus driving down network utilization. Moreover, additional LAGs across the transport network may be unnecessary given different approaches for protecting the transport network which may already be in place (e.g., Automatically Switched Optical Network (ASON) and/or Generalized Multi-Protocol Label Switching (GMPLS)). Accordingly, traditional LAGs may not be optimal if only a single L1 traffic path (e.g., ODU SNC) is desired. Alternatively, protection may be afforded by utilizing an additional “hot standby” hybrid services line module 230 in node 200; however, this approach can result in increased equipment cost and reduced line module utilization.